Aufbau und Bestandteile einer Meldungskodierung
Grundlegendes
Jede Meldung entspricht einer eindeutigen, 11-stellige Kodierung. Diese Kodierung bleibt unverändert, auch wenn der Text der Meldung mit der Zeit variiert werden kann. Es wird daher ausdrücklich empfohlen, auf diese 11-stelligen Kodierungen zu parsen.
Die Kodierungen sind in sich logisch und systematisch aufgebaut, so dass auch eine automatische Analyse, Gruppierung oder Zusammenfassung bei der Bearbeitung der Meldungen möglich ist.
Generelles Format
Bei diesem 11-stelligen Format haben einzelne Felder oder Gruppen von Feldern jeweils eine eigene Bedeutung. Die Kodierung unterscheidet dabei vier Blöcke, die zusammengefasst die komplette Kodierung bilden.
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
A | B | C | D |
- A: Klassifizierung
- B: Interface
- C: Komponente
- D: Code
A - Klassifizierung (Spalte 1)
Im ersten Feld findet sich die Klassifikation. Daraus ist ersichtlich, wie kritisch die Meldung ist.
1 | INFO, Success |
2 | INFO, Failed |
3 | WARNING, temporärer Fehler |
4 | WARNING, permanenter Fehler |
5 | ERROR, temporärer Fehler |
6 | ERROR, permanenter Fehler |
7 | TECHNICALERROR, temporärer Fehler |
8 | TECHNICALERROR, permanenter Fehler |
- INFO
DENIC hat einen Auftrag exakt so ausgeführt, wie er gestellt wurde oder DENIC informiert von sich aus, nicht als Rückmeldung auf einen Auftrag. - WARNING
DENIC hat einen Auftrag ausgeführt, aber mit Abweichungen vom gestellten Auftrag. - ERROR
DENIC hat einen fehlerhaften Auftrag nicht ausgeführt. - TECHNICALERROR
Der Auftrag wurde nicht verarbeitet aus Gründen, die nichts mit Form oder Inhalt des Auftrags zu tun haben, sondern aufgrund von technischen Problemen bei der Auftragsverarbeitung. - temporär
Der Fehler ist von vorübergehender Natur. Der Auftrag kann zu einem späteren Zeitpunkt noch einmal gestellt werden. In diese Kategorie fallen z.B. Fehler aufgrund von Nameservern, die vorübergehend nicht erreichbar sind. - permanent
Der Fehler ist von grundsätzlicher Art. Beispiel: Eine Domain im Status „invalid" kann nicht registriert werden.
B - Interface (Spalte 2)
In Feld 2 ist die genutzte Anwendung kodiert.
1 | Frei |
2 | Frei |
3 | RRI (.de) |
4 | RRI (.9.4.e164.arpa) |
5 | whois |
6 | schnittstellenunabhängig |
9 | Webapplikation |
B - Interface (Spalten 3 bis 5)
Die nachfolgenden drei Felder kennzeichnen das entsprechende Modul der Anwendung. Im allgemeinem sind die Modulbezeichnungen an die jeweilige Auftragsform oder Prozedur angelehnt.
Modulunabhängig bedeutet, dass die Meldung sich nicht auf eine bestimmte Auftragsform bezieht, sondern mit dem Objekt des Auftrags zu tun hat. 300 bezieht sich also z.B. generell auf einen Domainauftrag, unabhängig davon, ob es sich um ein CREATE (das wäre 310), ein UPDATE (das wäre 320), oder eine andere Auftragsform gehandelt hat.
000 | anwendungsunabhängig |
100 | LOGIN / LOGOUT |
200 | contactmodulunabhängig |
210 | CREATE (Contact) |
220 | UPDATE (Contact) |
300 | domainmodulunabhängig |
310 | CREATE (Domain) |
320 | UPDATE (Domain) |
330 | CHHOLDER |
340 | RENEW (ENUM- Domain) |
345 | Expire (ENUM- Domain) |
348 | Expire (DE- Domain) |
350 | DELETE |
360 | TRANSIT |
370 | CHPROV |
391 | CREATE-AUTHINFO1 |
392 | DELETE-AUTHINFO1 |
393 | CREATE-AUTHINFO2 |
394 | AuthInfo-expire |
400 | CHECK |
450 | INFO |
500 | RAI-modulunabhängig |
600 | QUEUE-modulunabhängig |
610 | QUEUE-READ |
650 | QUEUE-DELETE |